Solve Service Area
- URL:http://<nalayer-url>/solveServiceArea
- Version Introduced:10.0
Description
The solve operation is performed on a network layer resource of type service area (layerType is esriNAServerServiceArea).
You can provide arguments to the solve service area operation as query parameters defined in the parameters table below.
Added at 10.5
overrides lets you specify additional settings that can influence the behavior of the solver when finding solutions for the network analysis problems.
Added at 10.4
Pass in a complete JSON representation of a travel mode through travelMode and automatically set override values for various other parameters to quickly and consistently model cars, trucks, a type of truck, and so on.
Added at 10.3
Set travelMode and automatically set override values for various other parameters to quickly and consistently model cars, trucks, a type of truck, and so on.
Added at 10.2.1
timeOfDayIsUTC lets you specify whether timeOfDay is in UTC or the time zone of the facilities. By using UTC, you can have all service areas start or end at the same time regardless of which time zones the facilities are located in.
Added at 10.1
- M values: outputLines parameter supports a new value: esriNAOutputLineTrueShapeWithMeasure. If specified, returned routes, compressed geometry, service area lines will contain M values on each vertex.
- Z values: Service Area solvers supports a new returnZ parameter. If returnZ=true and the Service Area solver is running against Z-aware network dataset, service area lines will contain Z values on each vertex. Input point and line locations can have Z values on them.
saPolylines and saPolygons in the response include properties hasZ and/or hasM to indicate if they contain z or m values.
- An optional url property to specify input facilities, barriers, polylinebarriers or polygonbarriers. The url value contains a REST Query request to a Feature, Map or a GP service returning a JSON featureset. The advantage of using this format is that locations can be passed directly from a service endpoint as input to the NA operation, bypassing client as intermediate storage.
- UseHierarchy: Significantly improves performance of polygon generation. Cannot be used in conjunction with outputLines.
- TimeOfDay: 10.1 Service Area solver is time aware and can be used in conjunction with historic and real-time traffic information.
Request Parameters
Parameter |
Details |
---|---|
f |
Description: The response format. The default response format is html. Values: html | json |
facilities |
Description: The set of facilities loaded as network locations during analysis. Facilities can be specified using a simple comma / semi-colon based syntax or as a JSON structure. If facilities are not specified, preloaded facilities from the map document are used in the analysis. If an empty json object is passed ('{}') preloaded facilities are ignored. Syntax and Examples: Simple syntax: You can use a simple comma/semicolon-based syntax if you need to specify only facility point geometries in the default spatial reference or WGS84. Syntax: facilities=x1,y1; x2, y2; ...; xn, yn Example: facilities=-122.406, 37.7831; -122.405, 37.7827 JSON Structures: Using JSON structures, you can specify two types of facilities:
Features You can specify facility geometries as well as attributes using a more comprehensive JSON structure. The JSON structure can include the following properties:
Each feature in this array represents a facility and it contains the following fields:
Syntax:
Example:
Syntax 2: using url: //This option was added at 10.1.
Example:
Layer You can specify facilities by referencing a data layer in the map service. Attribute and spatial filters can also be applied on the layer. The JSON structure can include the following properties:
Syntax:
Example:
|
barriers |
Description: The set of barriers loaded as network locations during analysis. Barriers can be specified using a simple comma/semicolon-based syntax or as a JSON structure. If barriers are not specified, preloaded barriers from the map document are used in the analysis. If an empty json object is passed ('{}'), preloaded barriers are ignored. Syntax and Examples: Simple syntax: You can use a simple comma/semicolon-based syntax if you need to specify only barrier point geometries in the default spatial reference or WGS84. Syntax: barriers=x1,y1; x2, y2; ...; xn, yn Example: barriers=-122.406, 37.7831; -122.405, 37.7827 JSON Structures: Using JSON structures, you can specify two types of barriers:
Features You can specify barrier geometries as well as attributes using a more comprehensive JSON structure. The JSON structure can include the following properties:
Each feature in this array represents a barrier and it contains the following fields:
Syntax:
Example:
Syntax 2: using url: //This option was added at 10.1.
Example:
Layer You can specify barriers by referencing a data layer in the map service. Attribute and spatial filters can also be applied on the layer. The JSON structure can include the following properties:
Syntax:
Example:
|
polylineBarriers |
Description: The set of polyline barriers loaded as network locations during analysis. If polyline barriers are not specified, preloaded polyline barriers from the map document are used in the analysis. If an empty json object is passed ('{}'), preloaded polyline barriers are ignored. Syntax and Examples: JSON Structures: Using JSON structures, you can specify two types of barriers:
Features You can specify polyline barrier geometries as well as attributes using a more comprehensive JSON structure. The JSON structure can include the following properties:
Each feature in this array represents a barrier and it contains the following fields:
Syntax:
Example:
Syntax 2: using url: //This option was added at 10.1.
Example:
Layer You can specify polyline barriers by referencing a data layer in the map service. Attribute and spatial filters can also be applied on the layer. The JSON structure can include the following properties:
Syntax:
Example:
|
polygonBarriers |
Description: The set of polygon barriers loaded as network locations during analysis. If polygon barriers are not specified, preloaded polygon barriers from the map document are used in the analysis. If an empty json object is passed ('{}'), preloaded polygon barriers are ignored. Syntax and Examples: JSON Structures: Using JSON structures, you can specify two types of barriers:
Features You can specify polygon barrier geometries as well as attributes using a more comprehensive JSON structure. The JSON structure can include the following properties:
Each feature in this array represents a barrier and it contains the following fields:
Syntax:
Example:
Syntax 2: using url: //This option was added at 10.1.
Example:
Layer You can specify polygon barriers by referencing a data layer in the map service. Attribute and spatial filters can also be applied on the layer. The JSON structure can include the following properties:
Syntax:
Example:
|
travelMode |
//Added at 10.4 Travel modes provide override values that help you quickly and consistently model a vehicle or mode of transportation. By setting a travel mode, you don't need to explicitly set values for the following parameters:
Caution: When setting travelMode, the service overrides the values of the parameters listed above with those defined in the travel mode, even if you specify their values explicitly in the request. Example: To use an existing travel mode that was preconfigured in the service, the typical workflow would be:
|
attributeParameterValues |
Description: A set of attribute parameter values that can be parameterized to determine which network elements can be used by a vehicle. The parameter holding a vehicle characteristic is compared to a value coming from a descriptor attribute to determine whether or not a network element is traversible. For example, a parameterized restriction attribute can compare the height of your vehicle with a descriptor attribute that holds the clearance under overpasses through tunnels. If the vehicles height is greater than the clearance, the edge is restricted. Parameterized cost attributes that can reference other cost attributes and scale them, can also be used. This is useful when inclement weather like ice, fog, or heavy rain, descends on the study area and hinders normal flow of traffic. By having a parameter already outfitted on a cost attribute, travel-time expectations and traversible network paths can be adjusted with respect to changes in traffic speeds. Syntax:
Example:
|
defaultBreaks |
Description: A comma-separated list of doubles. The default is defined in the network analysis layer. |
excludeSourcesFromPolygons |
Description: A comma-separated list of string names. The default is defined in the network analysis layer. |
mergeSimilarPolygonRanges |
Description: If true, similar ranges will be merged in the result polygons. The default is defined in the network analysis layer. Values: true | false |
outputLines |
Description: The type of lines(s) generated. The default is as defined in the network analysis layer. If esriNAOutputLineTrueShape is specified, the useHierarchy parameter will be ignored since the hierarchy cannot be used. Values: esriNAOutputLineNone | esriNAOutputLineTrueShape | esriNAOutputLineTrueShapeWithMeasure |
outputPolygons |
Description: The type of polygon(s) generated. The default is as defined in the network analysis layer. Values: esriNAOutputPolygonNone | esriNAOutputPolygonSimplified | esriNAOutputPolygonDetailed |
overlapLines |
Description: Indicates if the lines should overlap from multiple facilities. The default is defined in the network analysis layer. Values: true | false |
overlapPolygons |
Description: Indicates if the polygons for all facilities should overlap. The default is defined in the network analysis layer. Values: true | false |
splitLinesAtBreaks |
Description: If true, lines will be split at breaks. The default is defined in the network analysis layer. Values: true | false |
splitPolygonsAtBreaks |
Description: If true, polygons will be split at breaks. The default is defined in the network analysis layer. Values: true | false |
trimOuterPolygon |
Description: If true, the outermost polygon (at the maximum break value) will be trimmed. The default is defined in the network analysis layer. Values: true | false |
trimPolygonDistance |
Description: If polygons are being trimmed, provides the distance to trim. The default is defined in the network analysis layer. |
trimPolygonDistanceUnits |
Description: If polygons are being trimmed, specifies the units of the trimPolygonDistance. The default is defined in the network analysis layer. Values esriUnknownUnits | esriInches | esriPoints | esriFeet | esriYards | esriMiles | esriNauticalMiles | esriMillimeters | esriCentimeters | esriMeters | esriKilometers | esriDecimalDegrees | esriDecimeters |
returnFacilities |
Description: If true, facilities will be returned with the analysis results. Default is false. The facilities are available in the facilities property of the JSON response. Values: true | false |
returnBarriers |
Description: If true, barriers will be returned with the analysis results. Default is false. The barriers are available in the barriers property of the JSON response. Values: true | false |
returnPolylineBarriers |
Description: If true, polyline barriers will be returned with the analysis results. Default is false. The polyline barriers are available in the polylineBarriers property of the JSON response. Values: true | false |
returnPolygonBarriers |
Description: If true, polygon barriers will be returned with the analysis results. Default is false. The polygon barriers are available in the polygonBarriers property of the JSON response. Values: true | false |
outSR |
Description: The well-known ID of the spatial reference for the geometries returned with the analysis results. If outSR is not specified, the geometries are returned in the spatial reference of the map. |
accumulateAttributeNames |
Description: The list of network attribute names to be accumulated with the analysis. The default is as defined in the network analysis layer. The value should be specified as a comma separated list of attribute names. You can also specify a value of none to indicate that no network attributes should be accumulated. Example: accumulateAttributeNames=WalkingMinutes,Meters |
impedanceAttributeName |
Description: The network attribute name to be used as the impedance attribute in analysis. The default is as defined in the network analysis layer. Example: impedanceAttributeName=DrivingMinutes |
restrictionAttributeNames |
Description: The list of network attribute names to be used as restrictions with the analysis. The default is as defined in the network analysis layer. The value should be specified as a comma separated list of attribute names. You can also specify a value of none to indicate that no network attributes should be used as restrictions. Example: restrictionAttributeNames=Oneway |
restrictUTurns |
Description: Specifies how U-Turns should be restricted in the analysis. The default is as defined in the network analysis layer. Values: esriNFSBAllowBacktrack | esriNFSBAtDeadEndsOnly | esriNFSBNoBacktrack | esriNFSBAtDeadEndsAndIntersections |
outputGeometryPrecision |
Description: The precision of the output geometry after generalization. If 0, no generalization of output geometry is performed. The default is as defined in the network service configuration. If present and positive, it represents the MaximumAllowableOffset parameter - generalization is performed according to IPolycurve.Generalize. Example: outputGeometryPrecision=0.5 |
outputGeometryPrecisionUnits |
Description: The units of the output geometry precision. The default value is esriUnknownUnits Values: esriUnknownUnits | esriCentimeters | esriDecimalDegrees | esriDecimeters | esriFeet | esriInches | esriKilometers | esriMeters | esriMiles | esriMillimeters | esriNauticalMiles | esriPoints | esriYards |
useHierarchy |
Description: If true, the hierarchy attribute for the network should be used in analysis. The default is as defined in the network layer. This cannot be used in conjunction with outputLines. Values: true | false |
timeOfDay |
Description: The date and time at the facility. If travelDirection is set to esriNATravelDirectionToFacility, the timeOfDay value specifies the arrival time at the facility. if travelDirection is set to esriNATravelDirectionFromFacility, the timeOfDay value is the departure time from the facility. The time zone for timeOfDay is specified by timeOfDayIsUTC. Values: specified by number of milliseconds since midnight January 1st, 1970. |
timeOfDayIsUTC |
This option was added at 10.2.1. Description: The time zone or zones of the timeOfDay parameter. When set to false, which is the default value, the timeOfDay parameter refers to the time zone or zones in which the facilities are located. Therefore, the start or end times of the service areas are staggered by time zone. Setting timeOfDay to 9:00 a.m., today and timeOfDayIsUTC to false causes service areas to be generated for 9:00 a.m. Eastern Time for any facilities in the Eastern Time Zone, 9:00 a.m. Central Time for facilities in the Central Time Zone, 9:00 a.m. Mountain Time for facilities in the Mountain Time Zone, and so on, for facilities in different time zones. The time is always 9:00 a.m. local time, but staggered in real time. (Even though local times are used in this example, timeOfDay is set as the number of milliseconds since midnight January 1, 1970 UTC to 9:00 a.m., today UTC, and the UTC time zone is ignored.) If stores in a chain that span the U.S. open at 9:00 a.m. local time, this parameter value could be chosen to find market territories at opening time for all stores in one solve. First, the stores in the Eastern Time Zone open and a polygon is generated, stores open an hour later in Central Time, and so on. A true value for timeOfDayIsUTC indicates the timeOfDay parameter refers to Coordinated Universal Time (UTC). Therefore, all facilities are reached or departed from simultaneously, regardless of the time zone or zones they are in. Setting timeOfDay to 2:00 p.m., today and timeOfDayIsUTC to true causes service areas to be generated for 9:00 a.m. Eastern Standard Time for any facilities in the Eastern Time Zone, 8:00 a.m. Central Standard Time for facilities in the Central Time Zone, 7:00 a.m. Mountain Standard Time for facilities in the Mountain Time Zone, and so on, for facilities in different time zones. (The 2:00 p.m., today UTC value is specified in timeOfDay as the number of milliseconds since midnight January 1, 1970 UTC to 9:00 a.m., today UTC.)
Note: The scenario above assumes standard time. During daylight saving time, the Eastern, Central, and Mountain times would each be one hour ahead (that is, 10:00, 9:00, and 8:00 a.m., respectively). One of the cases in which the UTC option is useful is to visualize emergency-response coverage for a jurisdiction that is split into two time zones. The emergency vehicles are specified in facilities. timeOfDay is set to now in UTC. (You need to determine the current time and date in UTC anc convert it to milliseconds to correctly use this option.) Other parameters are set, and the analysis is solved. Even though a time-zone boundary divides the vehicles, the results show areas that can be reached given current traffic conditions. This same process can be used for other times as well, not just for now. Values: true | false |
travelDirection |
Description: Options for traveling to or from the facility. The default is defined in the network analysis layer. Values: esriNATravelDirectionFromFacility | esriNATravelDirectionToFacility |
returnZ |
//This option was added at 10.1. Description: If true, Z values will be included in saPolygons and saPolylines geometry if the network dataset is Z-aware. The default is false. |
overrides | Specify additional settings that can influence the behavior of the solver when finding solutions for the network analysis problems. The value for this parameter needs to be specified in JavaScript Object Notation (JSON). The values can be either a number, Boolean, or a string.
The default value for this parameter is no value, which indicates not to override any solver settings. Overrides are advanced settings that should be used only after careful analysis of the results obtained before and after applying the settings. A list of supported override settings for each solver and their acceptable values can be obtained by contacting EsriTechnical Support. |
JSON Response Syntax
{
"saPolygons" : {
"spatialReference" : { <spatialReference> },
"hasZ": <true|false>,
"hasM": <true|false>,
"features" : [ <array of <polygon> features> ]
},
"saPolylines" : {
"spatialReference" : { <spatialReference> },
"hasZ": <true|false>,
"hasM": <true|false>,
"features" : [ <array of <polyline> features> ]
},
"facilities" : {
"spatialReference" : { <spatialReference> },
"hasZ": <true|false>,
"features" : [ <array of <point> features> ]
},
"barriers" : {
"spatialReference" : { <spatialReference> },
"hasZ": <true|false>,
"features" : [ <array of <point> features> ]
},
"polylineBarriers" : {
"spatialReference" : { <spatialReference> },
"hasZ": <true|false>,
"features" : [ <array of <polyline> features> ]
},
"polygonBarriers" : {
"spatialReference" : { <spatialReference> },
"features" : [ <array of <polygon> features> ]
},
"messages" : [ {<message1>}, {<message2>},... ]
}
where each features object is defined as:
"features": [
{
"attributes": {
"<field1>": <value11>,
"<field2>": <value12>
},
"geometry": {<geometry1>}
},
{
"attributes": {
"<field1>": <value21>,
"<field2>": <value22>
},
"geometry": {<geometry2>}
}
]
and each message is defined as:
{ "type" : <type1>, "description" : <description1> }
JSON Response Example
{
"saPolygons": {
"features": [
{
"attributes": {
"ObjectID": 1,
"FacilityID: 3,
"Name": "Some name",
"FromBreak": 0.0,
"ToBreak": 10.0,
"Shape_Length": 0.171641389705288
},
"geometry" : {
"rings" : [
[ [-97.06138,32.837], [-97.06133,32.836], [-97.06124,32.834], [-97.06127,32.832], [-97.06138,32.837] ],
[ [-97.06326,32.759], [-97.06298,32.755], [-97.06153,32.749], [-97.06326,32.759] ]
],
"spatialReference" : {"wkid" : 4326}
}
}
]
},
"facilities" : {
"features": [
{
"attributes": {
"ObjectID": 1,
"Name": "Location 1",
"Sequence": 1,
"TimeWindowStart": null,
"TimeWindowEnd": null,
"ArriveCurbApproach": 1,
"DepartCurbApproach": 2
},
"geometry": { "x": -122.4079, "y": 37.7835 }
},
{
"attributes": {
"ObjectID": 2,
"Name": "Location 2",
"Sequence": 2,
"TimeWindowStart": null,
"TimeWindowEnd": null,
"ArriveCurbApproach": 1,
"DepartCurbApproach": 2
},
"geometry": { "x": -122.3931, "y": 37.79496 }
}
]
},
"barriers": {
"features": [
{
"attributes": {
"ObjectID": 1,
"Name": "Barrier 1",
"SourceID": 1,
"SourceOID": 9619,
"PosAlong": 0.841037735851507,
"SideOfEdge": 2,
"CurbApproach": null,
"Status": 0
},
"geometry": { "x": -122.41, "y": 37.7889 }
}
]
},
messages": [
{
"type": 50,
"description": "Some message 1."
},
{
"type": 50,
"description": "Some message 2."
}
]
}